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REMARKS 

Claims 1-3, 5-8, 10-13, and 15 were rejected in the Official Action mailed August 19, 
2005. In response, Applicant respectfully requests reconsideration. In this Response After Final, 
no claims are added, canceled, or amended so that claims 1-3, 5-8, 10-13, and 15 remain at issue. 

I. Rejections Under 35 U.S.C. § 112, First Paragraph 

Claims 1, 3, 5, 6, 8, 10, 11, 13, and 15 were rejected under 35 U.S.C. § 112, first 
paragraph, as allegedly failing to comply with the written description requirement. Applicant 
respectfully traverses this rejection. 

To satisfy the written description requirement, a patent specification must describe the 
claimed invention in sufficient detail that one skilled in the art can reasonably conclude that the 
inventor had possession of the claimed invention. Moba, B, V. v. Diamond Automation, Inc., 325 
F.3d 1306, 1319, 66 USPQ2d 1429, 1438 (Fed. Cir. 2003). However, the Examiner has the 
initial burden of presenting by a preponderance of evidence why a person skilled in the art would 
not recognize in an applicant's disclosure a description of the invention defined by the claims. In 
re Wertheim, 541 F.2d 257, 263, 191 USPQ 90, 97 (CCPA 1976). Applicant respectfully 
submits that the Examiner has failed to establish a prima facie case that a person skilled in the art 
at the time the application was filed would not have recognized that the inventor was in 
possession of the invention as claimed in view of the disclosure of the application as filed. 

With regard to claim 1, the Examiner asserts that the limitations "said proxy object 
translating said method call from said intermediary protocol to a second protocol" and "said 
proxy object issuing said method call to a method using said second protocol" are not described 
in the application as filed. The Examiner contends that the application does not disclose what 
performs the translating or the issuing of the method call, and thus does not teach that a proxy 
object that performs the translating and the issuing of the method call. However, the 
specification clearly states that the proxy object indeed performs the translating from the 
intermediary protocol to the second protocol and issuing a method call using the second protocol. 
The specification, at page 6, lines 19-24, states: 
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At step 100, a proxy object is created in the calling code. The 
proxy object translates calls from the language of the calling code 
to the * Connect protocol. At step 110, a method of the proxy 
object is called according to the protocol of the language of the 
calling code. At step 120, the call is translated into the *Connect 
protocol. At step 130, the call is translated, or marshaled, into the 
protocol of the method's language. At step 140, the call is 
dispatched to the method. 

Once the proxy object method is called at step 110, it is clear the proxy object is performing 
steps 120-140. The specification clearly states that the proxy object is the actor in step 120. It 
logically follows that the proxy object remains the actor for the second translating step 130 until 
after the call is dispatched step 140. Moreover, the specification goes on, at page 6, line 25 to 
page 7, line 3, to state: 



At step 160, the return value is sent back to the proxy object. At 
step 170, the proxy object translates the return value from the 
protocol of the method's language to the *Connect protocol. At 
step 180, the proxy object translates the return value from the * 
Connect protocol to the protocol of the language of the calling 
code. 

Because the specification describes that the value is being sent back to the proxy object, it is both 
obvious and implicit that it was the proxy object that translated and dispatched the call. 
Moreover, the specification explicitly describes the proxy object doing the reverse of step 130 at 
step 170. Because the proxy object is explicitly described as translating between the method's 
language to the protocol language, Applicant clearly contemplated that the proxy object also 
performed this function at step 130, Thus, the ordinarily skilled artisan would more likely than 
not recognized that the inventors were in possession of the invention as claimed in view of the 
disclosure of the application as filed 

Applicant respectfully submits that the rejection is erroneous and should be withdrawn. 
Because claims 6 and 11 recite limitations similar to those of claim 1, the rejection of claims 6 
and 1 1 is erroneous for at least the same reasons as given for claim 1. The rejection of claims 3, 
5, 8, 10, 13, and 15 is also erroneous as those claims depend from claims 1, 6, and 11, 
respectively. 
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IL Rejections Under 35 U.S.C. § 102 

Claim 1, 6, and 1 1 were rejected as being allegedly anticipated by Weber (U.S. Patent No. 
6,480,901). Applicant respectfully traverses this rejection. In Applicant's response mailed 
September 7, 2004, Applicant traversed this same rejection. However, the Examiner has offered 
no answer the substance of Applicant's argument in that response. "Where the applicant 
traverses any rejection, the examiner should, if he or she repeats the rejection, take note of the 
applicant's argument and answer the substance of it." (MPEP § 707.07(f)). Accordingly, that 
argument is repeated here, and an answer is respectfully requested. For the same reasons, 
Applicant requests that the finality of the rejection be withdrawn. 

Applicant respectfully submits that Weber fails to disclose or even suggest creating a 
proxy object that translates a method call from a first protocol to a second protocol. Weber 
discusses creating a proxy object, however, Weber's proxy object is clearly unlike Applicant's 
claimed proxy object. Referring to Weber's Figure 8, Weber teaches a method for issuing 
remote procedure calls from a management station 802 to a storage controller 806. A 
management interface application 830 at the management station 802: 

initiates a proxy object to represent the storage system's object 
graph on management station 802. That is, management interface 
application 820 [sic] stores a copy of the storage system's object 
graph on management station 802, so it can access and display the 
object graph when necessary. After retrieving the storage systems 
organization and configuration, management interface application 
830 displays the storage system's configuration on a display screen, 

(Column 17, lines 30-37 of Weber). 

Thus, unlike Applicant's claimed proxy object, Weber's proxy object does not have a 
method call issued to it, does not translate a method call from a first protocol to an intermediate 
protocol, does not translate a method call from an intermediate protocol to a second protocol, and 
does not issue a method call to a method using a second protocol. Instead, Weber's proxy object 
merely represents a storage system's object graph. 
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Moreover, the Examiner relies on RPC conversion agent 522 and UTM-to-internal- 
messaging component 526 to purportedly teach the method in claim 1. As previously discussed, 
RPC conversion agent 522 is not the proxy agent in Weber. Nevertheless, RPC conversion agent 
522 and UTM-to-internal-messaging component 526 are two entirely different components in 
Weber: one is located on a server and the other is located on a device controller. (See Figure 5 of 
Weber). In contrast, claim 1 is directed to a single proxy object that is capable of performing 
both translations by itself. Accordingly, the RPC conversion agent 522 and UTM-to-internal- 
messaging component 526 cannot be relied upon in combination to anticipate claim 1 . Therefore, 
for at least these reasons, Weber fails to teach or even suggest Applicant's claims 1, 6, and 11. 

Applicant respectfully submits the rejection has been overcome and requests that it be 
withdrawn. 

III. Rejection Under 35 U.S.C. S 103 

Claims 3, 5, 8, 10, 13, and 15 were rejected under 35 U.S.C. §103(a) as being allegedly 
unpatentable over Weber in view of Bandhauer ("A zero generated code XPConnect proposal"). 
Applicant respectfully traverses the rejection. In Applicant's response mailed September 7, 2004, 
Applicant traversed this same rejection. However, the Examiner has offered no answer the 
substance of Applicant's argument in that response. "Where the applicant traverses any rejection, 
the examiner should, if he or she repeats the rejection, take note of the applicant's argument and 
answer the substance of it." (MPEP § 707.07(f)). Accordingly, that argument is repeated here, 
and an answer is respectfully requested. For the same reasons, Applicant requests that the 
finality of the rejection be withdrawn. 

Independent claims 1, 6, and 11 are allowable over Weber as discussed above. 
Bandhauer still fails to disclose or suggest Applicant's claimed proxy object. The Examiner 
argues that XPConnect is an intermediate protocol, however, Applicant disagrees. XPConnect is 
a technology that binds JavaScript types to XPCOM types. {See, e.g., Creating Applications 
with Mozilla, http:^ooks.mozdev.org/html/mozilla-chp-8.html (O'Reilly & Assoc. 2002)). 
With XPConnect, an XPCOM object is called and instantiated from JavaScript. Id. For 
JavaScript to call and instantiate the XPCOM object, XPConnect provides a bridge to bind 



Response After Final to August 19, 2005 Office Action 
Application No. 09/865,660 
Page 9 

JavaScript types to XPCOM types. Id. In XPConnect, XPCOM interfaces and IDs are stored as 
global JavaScript objects and properties that can be manipulated. Id. 

Therefore, Bandhauer fails to disclose or suggest creating a proxy object that converts a 
first protocol into an intermediate protocol and converts the intermediate protocol into a second 
protocol. Instead, Bandhauer discusses XPConnect, which binds JavaScript types to XPCOM 
types. Accordingly, Weber in view of Bandhauer still fails to disclose or suggest claims 1, 6, 
and 11. 

Claims 3, 5, 8, 10, 13, and 15 depend directly or indirectly from claim 1, 6, or 1 1 and are 
therefore allowable for at least the same reasons that claims 1, 6, and 1 1 are allowable. 

Applicant respectfully submits the rejection has been overcome and requests that it be 
withdrawn. 

IV. Conclusion 

Applicant respectfully submits that claim 1, 3, 5, 8, 10, 11, 13 and 15 are allowable over 
the cited prior art, and respectfully requests early and favorable notification to that effect. 
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